The present invention relates to computer networks and, more particularly, to management of entities in a multi-protocol computer network.
Data communications in a computer network involves the exchange of data between two or more entities interconnected by communication links and subnetworks. These networks are typically software programs executing on hardware computer platforms which, depending on their roles within a network, may serve as host stations, end stations or intermediate stations. Examples of intermediate stations include routers, bridges and switches that interconnect communication links in subnetworks; an end station may be a computer located on one of the subnetworks. More generally, an end station connotes a source of or target for data that typically does not provide routing or other services to other computers on the network. A local area network (LAN) is an example of a subnetwork that provides relatively short-distance communication among the inter-connected stations; in contrast, a wide area network (WAN) facilitates long-distance communication over links provided by public or private telecommunications facilities.
End stations typically communicate by exchanging discrete packets or frames of data according to predefined protocols. In this context, a protocol represents a set of rules defining how the stations interact with each other to transfer data. Such interaction is simple within a LAN, since these are typically xe2x80x9cmulticastxe2x80x9d networks: when a source station transmits a frame over the LAN, it reaches all stations on that LAN. If the intended recipient of the frame is connected to another LAN, the frame is passed over a routing device to that other LAN. Collectively, these hardware and software components comprise a communications network and their interconnections are defined by an underlying architecture.
Most computer network architectures are organized as a series of hardware and software levels or xe2x80x9clayersxe2x80x9d within each station. These layers interact to format data for transfer between, e.g., a source station and a destination station communicating over the network. Specifically, predetermined services are performed on that data as it passed through each layer, and the layers communicate with each other by means of the pre-defined protocols. This design permits each layer to offer selected services to other layers using a standardized interface that shields the other layers from details of actual implementation of the services. The lower layers of these architectures are generally standardized and implemented in hardware and firmware, whereas the higher layers are usually implemented in the form of software. Examples of such communications architectures include the System Network Architecture (SNA) developed by International Business Machines (IBM) Corporation and the Internet Communications Architecture.
The Internet architecture is represented by four layers termed, in ascending interfacing order, the network interface, internetwork, transport and application layers. The primary internetwork layer protocol of the Internet architecture is the Internet Protocol (IP). IP is primarily a connectionless protocol that provides for internetworking routing, fragmentation and reassembly of exchanged packetsxe2x80x94generally referred to as xe2x80x9cdatagramsxe2x80x9d in an Internet environmentxe2x80x94and which relies on transport protocols for end-to-end reliability. An example of such a transport protocol is the Transmission Control Protocol (TCP), which is implemented by the transport layer and provides connection-oriented services to the upper layer protocols of the Internet architecture. The term TCP/IP is commonly used to denote this architecture; the TCP/IP architecture is discussed in Computer Networks, 3rd edition, by Andrew S. Tanenbaum, published by Prentice-Hall, PTR in 1996, all disclosures of which are incorporated herein by reference, particularly at pages 28-54.
SNA is a communications framework widely used to define network functions and establish standards for enabling different models of IBM computers to exchange and process data. SNA is essentially a design philosophy that separates network communications into several layers termed, in ascending order, the physical control, the data link control, the path control, the transmission control, the data flow control, the presentation services and the transaction services layers. Each of these layers represents a graduated level of function moving upward from physical connections to application software.
In the SNA architecture, the data link control layer is responsible for transmission of data from one end station to another. Bridges or devices in the data link control layer that are used to connect two or more LANs so that end stations on either LAN are allowed to access resources on the LANs. Connection-oriented services at the data link layer generally involve three distinct phases: connection establishment, data transfer and connection termination. During connection establishment, a single path or connection, e.g., an IEEE 802.2 logical link control type 2 (LLC2) or xe2x80x9cdata link controlxe2x80x9d connection, is established between the source and destination stations. Once the connection has been established, data is transferred sequentially over the path and, when the LLC2 connection is no longer needed, the path is terminated. Reliable communication of the LLC2 (DLC) is well known and described by Andrew Tanenbaum in his book Computer Networks, Second Edition, published in 1988, all disclosures of which are incorporated herein by reference, especially at pages 253-257.
FIG. 1 is a schematic block diagram of a conventional computer network 100 having a host computer coupled to a Token Ring (TR) network TR1 and an end station coupled to TR2. The TR networks are of the type that support Source/Route Bridging (SRB) operations with respect to the contents of a routing information field (RIF) of a frame. The host computer is preferably a SNA host entity comprising a host mainframe computer 110 coupled to a channel-attached router or a front end processor (FEP), such as an IBM 3745 network control processor, hereinafter referred to as the xe2x80x9chost network connectionxe2x80x9d 112. In addition, the end station is an SNA entity 114 comprising a xe2x80x9cphysical unitxe2x80x9d (PU) and a xe2x80x9clogical unitxe2x80x9d (LU) which consists of logical services by which a user may access the SNA network. A control unit 106 (such as IBM 3174) interconnects TR1 and TR2 such that the SRB network 100 effectively functions as a LAN. SNA protocols, such as a hierarchical sub-area SNA protocol that defines a connection path between the PU and host, are used throughout the network.
In an alternate embodiment of network 100, Remote Source Route Bridging (RSRB) routers 1,2 operate in conjunction with the host network connection 112 to provide IP connectivity over a TCP/IP cloud 110 with the SNA network 100. RSRB is a software component in each router that permits transmission of TR frame traffic across an IP network. Specifically, RSRB functions to give the IP network the appearance of a single, virtual token ring (VTR) xe2x80x9chopxe2x80x9d in a TR network. The association of the two adjacent RSRB routers is called a xe2x80x9cpeerxe2x80x9d relation and this relation must exist to exchange RSRB traffic across the VTR.
The PU entity communicates with the host by exchanging TR frames over LLC2 connections or sessions through the SRB network. Each TR frame 120 includes a RIF 122 that contains source route information in the form of ring number/bridge number pair xe2x80x9chopsxe2x80x9d within a path between the stations. An LLC2 session is established between the stations using a special TR frame, called an explorer frame. The explorer frame is used by a source (PU) to xe2x80x9cdiscoverxe2x80x9d the path to a destination (host); thereafter, a Set Asynchronous Balanced Mode Extended (SABME) frame is sent from the PU to the host to establish a logical connection between the end stations, and the host responds to the SABME frame with an Unnumbered Acknowledgment (UA) frame. Once the UA frame is received by the PU, a connection is established between the source and destination, and these stations communicate by exchanging TR information (INFO) and acknowledgment frames until the logical link SNA session is completed.
For example, the PU transmits an INFO frame over TR2 and through the control unit and TR1 to the host. Upon successfully receiving the INFO frame, the host responds by transmitting an LLC2 Receive/Ready (RR) acknowledgment frame over the SRB network to the PU. This INFO/RR exchange continues until the PU has successfully transmitted all of its data and the host has successfully received all of that data. Session completion is then initiated by a Disconnected Mode (DM) frame being transmitted from the PU to the host; the disconnection is thereafter acknowledged by the host responding with a UA frame. The LLC2 frames (packets) are described by Radia Perlman in her book Interconnections, Bridges and Routers, published by Addison Wellesly Publishing Company, in 1992, all disclosures in which are incorporated herein by reference, particularly at pages 33-34.
In a SNA network, applications executing on end stations typically access the network through LUs of the stations; accordingly, in a typical SNA network, a communication session may connect two LUs in a LU-LU session. Advanced Peer to Peer Networking (APPN) functions generally include session establishment and session routing within an APPN network. FIG. 2 is a schematic block diagram of an APPN network 200 comprising a host 202 coupled to a host network connection entity 206 and a PU entity 212 coupled to token ring (TR) LAN TRI. During session establishment, an end station (such as PU 212) requests an optimum route for a session between two LUs; this route is calculated and conveyed to PU 212 by an intermediate station (e.g., station 216) via a LOCATE message exchange through the network 200. Thereafter, a xe2x80x9cset-upxe2x80x9d or BIND message is forwarded over the route to initiate the session. The BIND includes information pertaining to the partner LU requested for the session.
Intermediate session routing occurs when the intermediate station 216, configured as an APPN network node (NN), is present in a session between the two end nodes. As can be seen, the APPN network node is connected to an APPN/WAN 210 that includes additional APPN NNs to extend the APPN architecture throughout the network. The APPN network nodes forward packets of a LU-LU session over the calculated route between the two APPN end nodes. An APPN network node is a fill-functioning APPN router node having all APPN base service capabilities, including session services functions. An APPN end node, on the other hand, is capable of performing only a subset of the functions provided by an APPN network node. APPN network and end nodes are well-known and are, for example, described in detail in Systems Network Architecture Advanced Peer to Peer Networking Architecture Reference IBM Doc SC30-3422 and APPN Networks by Jesper Nilausen, printed by John Wiley and Sons, 1994, at pgs 1-83.
The APPN router node may provide Dependent LU Requester (DLUR) services on behalf of the PU (xe2x80x9cdependentxe2x80x9d LU) in network 200 while a virtual telecommunication access method (VTAM) on the host 202 may provide Dependent LU Server (DLUS) services. The DLUS host may be coupled to the DLUR router by way of a xe2x80x9cpipexe2x80x9d connection over which control traffic for the dependent session flows. The DLUR router essentially functions as a xe2x80x9csurrogatexe2x80x9d for the downstream PU with respect to the DLUS host such that the control information flows over the network to the PU by way of the DLUR router.
Data Link Switching (DLSw) is a mechanism for forwarding SNA protocol frames over, e.g., a TCP/IP backbone WAN such as the Internet. In traditional bridging, the data link connection is end-to-end, i.e., effectively continuous between communicating end stations. A stream of data frames originating from a source station on a source LAN traverses one or more bridges specified in the path over the LLC2 (DLC) connection to a destination station on a destination LAN. In a network implementing DLSw, by contrast, the LLC2 connection terminates at a local DLSw device entity, e.g., a router. An example of a DLSw network arrangement may comprise a host DLSw router connected to a host computer via a host LAN and a remote DLSw router connected to a remote LAN having a destination station. The LANs that are accessed through the DLSw routers may appear as SRB subnetworks attached to adjacent rings; each of these adjacent rings manifest as a virtual ring within each DLSw router that effectively terminates the SRB network.
A DLSw network is formed when two DLSw devices interconnect the end nodes of a SNA network by way of the IP network; the DLSw devices preferably communicate using a Switch-to-Switch protocol (SSP) that provides packet xe2x80x9cbridgingxe2x80x9d operations at the LLC (i.e., DLC) protocol layer. FIG. 3 is a schematic block diagram of a DLSw network 300 having a TCP/IP cloud 310 disposed between host and remote SRB subnetworks 320, 330. Each SRB subnetwork comprises a DLSw router 1, 2 coupled to a host/host is network connection 302, 304 and PU/LU 312 via TR1 and 2, respectively. The DLSw routers function as end points between TCP sessions over the TCP/IP cloud when transporting TR frames associated with DLC sessions over that intermediate network. In an alternate embodiment of network 300, RSRB routers 1, 2 may be substituted for DLSw routers 1, 2.
Broadly stated, each DLSw router establishes a xe2x80x9cpeer relationshipxe2x80x9d to the other DLSw router in accordance with a conventional capabilities exchange message sequence, and the logical and physical connections between these routers connect the subnetworks into a larger DLSw network. To establish a peer connection in accordance with an implementation of DLSw switching, the host DLSw router first opens logical TCP (Read/Write) xe2x80x9cpipexe2x80x9d connections to the remote DLSw router using a conventional socket technique to create a socket into the transport layer of the protocol stack. Once the TCP pipes are established, the SSP protocol is used to transport the capabilities exchange messages between the two DLSw routers.
The capability exchange messages contain various parameters, such as the number of pipes used for communicating between the DLSw routers and the largest frame size supported by the routers. Each DLSw router responds to each capability exchange message issued by its peer router with a capability exchange response message. Upon completion of the exchange, each router reconfigures itself to xe2x80x9cact uponxe2x80x9d the agreed capabilities and the peer connection is established. Establishment of a peer connection can occur automatically upon xe2x80x9cboot-upxe2x80x9d of each DLSw router; that is, as soon as a DLSw router activates, it connects with its DLSw peer. The DLSw forwarding mechanism is well known and described in detail in Request For Comment (RFC) 1795 by Wells and Bartky, 1995 at pgs 1-91.
DLSw routers can establish multiple parallel TCP sessions using well-known port numbers. All frames associated with a particular LLC2 connection typically follow a single designated TCP session. Accordingly, SNA data frames originating at the PU are transmitted over a particular LLC2 connection along TR2 to DLSw2, where they are encapsulated within a designated TCP session and transported over the TCP/IP cloud 310. The encapsulated messages are received by DLSw1, decapsulated to their original frames and transmitted over a corresponding LLC2 connection of TRI to the host in the order received by DLSw2 from the PU.
The LLC2 connection between the PU and host is identified by a data link identifier (ID) 360 consisting of a pair of attachment addresses associated with each end station. Each attachment address is represented by the concatenation of a media access control (MAC) address (6 bytes) and a LLC service access point (SAP) address (1 byte). Specifically, each attachment address is classified as either a target address comprising a destination MAC (DMAC) and a destination SAP (DSAP), or an origin address comprising a source MAC (SMAC) and source SAP (SSAP) addresses. The attachment addresses are contained in the TRs frame exchanged between the PU and host entities.
Furthermore, the designated TCP session is identified by a pair of circuit IDs 370, each comprising a 64-bit number that identifies the LLC2 circuit within a DLSw circuit. The DLSw circuit ID generally comprises a data link circuit port ID (4 bytes) and a data link correlator (4 bytes). A pair of circuit IDs along with a data link ID uniquely identifies a single end-to-end circuit through the network. Notably, each DLSw router maintains a table 350 comprising a plurality of data link ID and corresponding DLSw circuit ID pair entries. In order to associate LLC2 frame traffic with a corresponding DLSw circuit when communicating over the IP cloud, each DLSw router typically indexes into the table (the xe2x80x9cDLSw tablexe2x80x9d) using a data link ID to find the corresponding DLSw circuit IDs.
FIG. 4 is a schematic block diagram of a conventional network 400 wherein a host mainframe 402 is coupled to a Telnet 3270 server 404, which preferably executes on a channel-attached router. The TN3270 router is coupled to an end station 408 over a TCP/IP cloud 406. Here, the end station 408 employs the TCP/IP protocol to establish a SNA connection with the host via a telnet connection with the TN3270 router. The Telnet connection is well known to the Internet community and described in RFCs 854, 860 and 862.
When managing a multi-protocol TCP/IP-based SNA network, the routers and protocols used for carrying the SNA sessions, along with information pertaining to the protocols, must be known in order to diagnose points of failure for those sessions behaving improperly or to determine the sessions that may be affected when performing maintenance on the routers. For example in DLSw network 300, information about the DLSw protocols used to transport SNA session traffic is available to a network operator of a network management station (NMS) 380 via a Simple Network Management Protocol (SNMP). The DLSw circuit information described above, including the data link IDs, are available to the NMS 380 by accessing DLSw management information base (MIB) tables within the routers using SNMP. The MIB and SNMP protocol, and their use in providing network management information between SNMP management stations and agents are well-known and described in, e.g., SNMP, SNMPv2 and RMON by William Stallings, printed by Addison Wesley Publishing Company, 1996.
An outage involving a PU session in the network 300 may be diagnosed by the network operator using a conventional approach that correlates SNA frame traffic sessions to DLSw routers for a network having a peer connection over an IP cloud between DLSw peer routers. Typically, management of the SNA entities takes place on the host in accordance with a network management application program, such as NetView, executing on the host. The application can access the status of the PU entity by virtue of its definition contained in a specialized data structure 390 of the host network connection. This data structure is a VTAM table 390 having entries whose contents define all the PUs with respect to the host. The content definitions of the entries comprise a name (e.g. PU name 392) along with an identifier block number/identifier number (IDBLK/IDNUM 394) or control point (CP) name that uniquely identifies each PU on a network at a given time.
The NetView application manages those SNA resources known to it; as used in this context, the term xe2x80x9cmanagingxe2x80x9d means that the application program can check and change the status of the resources, and can further control those resources to acquire, e.g., information leading to the traffic patterns of the resources. However, the NetView application cannot manage the component in the routers that encapsulate SNA traffic. As noted, the DLSw routers are preferably managed by the SNMP tool executing on the NMS which communicates with SNMP agents resident on the routers.
According to the conventional approach, the NMS communicates with an SNMP agent in each DLSw router to acquire DLSw MIB information including a data link ID identifying a DLSw circuit associated with the router. Since the host computer xe2x80x9cownsxe2x80x9d SNA sessions in the network, it maintains SNA-specific information (in addition to the PU name) such as the MAC/SAP addresses 396 for the host network connection and the PU on VTAM 390 in the host. A SNA View application is also resident on the host and used to acquire the MAC/SAP addresses and PU names. SNA View also communicates with VTAM to collect static definition information associated with the PU name if the PU is statically defined.
A complementary version of SNA View (i.e., CiscoWorks Blue SNA View) executes on the NMS and communicates with the host application over a logical TCP/IP (or LU 6.2) xe2x80x9cpipexe2x80x9d connection 385. The SNA View application on the NMS obtains the SNA-specific information from VTAM 390 over the pipe 385 and stores that information on a storage repository, such as a NMS database 382, of the NMS. In the case of DLSw network 300, the SNA-specific information retrieved from VTAM does not include information with respect to the DLSw routers that are routing the session traffic. Using the PU name of a session, an SNMP manager on the NMS may then correlate local and remote MAC/SAP addresses to the PU name in accordance with a conventional correlation procedure. Thereafter, the NMS can draw the topology of the DLSw network, including the DLSw circuit and PU session, to isolate any failures in the network.
A typical problem that arises with each of the networks of FIGS. 1-4 is that a customer cannot connect an end station into the network. As a result, the customer calls a network operater which uses conventional tools (such as CiscoWorks Blue SNA View and various CiscoWorks Blue Maps products) to diagnose the problem in the particular network. For example, the SNA View tool may be used to diagnose network 100 (FIG. 1), an APPN Maps application tool may be used to diagnose network 200 (FIG. 2), DLSw Maps and RSRB Maps application tools may be used for the configurations of FIG. 3, and a TN3270 monitor application may be used to diagnose network 400 (FIG. 4). The TN3270 monitor provides a list of PU sessions and status within a TN3270 network.
Utilizing these conventional tools, the NMS may display sessions of a particular protocol and perform a certain level of xe2x80x9cfilteringxe2x80x9d (i.e., searching) within the protocol. For example if the customer provides the name of the end station (PU) that cannot connect into the network, then the operator may invoke the SNA View tool to search for sessions based on that PU name because SNA traffic applies across all of the network configurations of FIGS. 1-4. The NMS may thus filter and display, e.g., all physical unit (PU) sessions known to VTAM and all VTAM PU sessions having names starting with a particular character sequence. SNA View would also enable display of the active/inactive status and other relevant information pertaining to the session.
To obtain further information, the operator investigates use of all available protocol tools, particularly if the customer has no detailed knowledge of its installed network. For example, the operator may invoke the APPN Maps and DLSw Maps tools to determine whether they have any knowledge of the particular PU session. The DLSw Maps tool includes a display screen that allows input of filtering criteria, such as a PU name. In response to the criteria, the tool provides a list of DLSw circuits that represent (carry) PU sessions and that meet the particular filter criteria. The circuit information includes local and remote MAC/SAP addresses of the circuits. The CiscoWorks SNA View product enables access to the VTAM information in the host to allow correlation between the DLSw circuit information and the PU names from VTAM using the MAC/SAP addresses. However, these conventional tools cannot provide a list of circuits (sessions) based on filter criteria without specifying the protocol.
Thus, it would be desirable to show all sessions in a network, regardless of protocol, that have a particular filter criteria, such as a PU name, MAC/SAP address or IP address of the PU. The present invention is directed to a technique for obtaining SNA PU session information pertaining to the filter criteria. In addition, the invention is generally directed to discovering the type of protocols used in network at a customer site without having to rely on the customer for specific information. In particular, the invention is directed to a technique for identifying a session in a customer""s network without knowledge of the protocols being employed.
The present invention comprises a technique for identifying a data session flowing through entities of a multi-protocol network based on information contained within a service request provided by a user of the network and without requiring knowledge of the protocols used by the session. The entities comprise a System Network Architecture (SNA) host mainframe (xe2x80x9chostxe2x80x9d), an end station and intermediate stations, such as routers. Information about the protocols used in the network is initially acquired by a network management station (NMS) coupled to the network. In the case of an SNA data session, information about the session is acquired from a virtual telecommunications access method (VTAM) table on the host and from management information bases (MIBs) provided by routers executing protocols utilized by the SNA session.
The NMS comprises a translation server configured to translate the service requests into session parameters for use by a novel correlation engine. The NMS further comprises an application protocol server including a plurality of protocol servers, each of which is configured to obtain specific protocol-related information pertaining to the session. In the illustrative embodiment, the protocol servers include a VTAM protocol server, a Data Link Switching (DLSw) protocol server, a Remote Source Route Bridging (RSRB) protocol server, a Telnet (TN3270) protocol server and an Advanced Peer to Peer Networking (APPN) protocol server. Information used by the application protocol server is stored on a NMS repository that is preferably organized as a plurality of tables, each containing protocol-related information associated with a protocol server.
In response to receiving the session parameters from the translation server, the correlation engine creates at least one filter containing searching criteria pertaining to session. For an SNA session, the criteria may comprise one or more of the following elements: Logical Unit (LU) name, LU status, Physical Unit (PU) name, PU status, PU type, is identifier block number/identifier number (IDBLK/IDNUM), media access control (MAC) address (with or without service access point (SAP) address), Control Point (CP) name, Dependent Logical Unit Requester (DLUR) name, Dependent Logical Unit Server (DLUS) name, DLUS status, end station (workstation) TCP/IP host name or address (with or without port number), router TCP/IP host name or address and the desired protocols. The correlation engine passes the filter to an appropriate protocol server to search its table of the repository (or its respective MIB) for information relevant to the request. If found, the protocol server returns a list of sessions (and associated information) matching the filter.
According to the inventive technique, the initial list of sessions returned by a protocol server becomes the working list. Subsequent session lists returned by the protocol servers are merged with the working list. That is if a subsequent session list includes information that matches information about a session in the working list, then the two sessions are considered the same and the session information from each protocol is combined into a single session. If the subsequent session list information does not match the information pertaining to any working list session, then the subsequent session list information is added to the working list as a new session. Partial matching of the session list generally indicates that the sessions are not identical; therefore an additional multiple criteria matching operation is performed to determine whether the sessions are similar. As each session is merged into the working list, flags are asserted to indicate which protocols have information about the session and which filters were satisfied by session returned by the protocol server.
A next stage of the technique involves sorting of the working list session entries based on whether the sessions match all of the filters (the highest order) and by PU name, if present. Each session of the working list that matches all of the filter criteria is flagged as matching the requested filters. The session that matches all of the filters supplied to all of the protocol servers is first in the list. If there are multiple sessions that meet the filter criteria, those sessions are further sorted by PU name. Thereafter, sessions are sorted by the highest number of partially matched filtering criteria. The resulting sessions are returned to the user, preferably in a session table format.
Advantageously, the invention provides an interface for a network operator of a NMS to locate any managed session in its network by entering whatever data it knows about the session. The correlation engine responds by returning a list of sessions sorted by the number of matches. By returning all sessions that match any filter criteria instead of just those sessions that match all of the criteria, the inventive technique avoids issues created when the operator mistakenly enters conflicting information. Moreover, the inventive technique enables the correlation engine to choose a session from potentially many sessions as a correct session for the filtering criteria.